Tom,

My current configuration just uses the default timing, so I will change the pulse length and try again tonight when I get time in front of the machine.

On my previous machines, the default timing has seemed to work fine with your KStep driver. This is the first machine setup that I have interpreted long 3D surfacing g-code sequences with, so I guess it could just be statistics and the type of motion that is making the issues show up now.

In the runs tonight I'll also find an encoder to couple to the motor shaft for better resolution on the magnitude and timing or the error.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi gradient_systems,
>
> Have you executed this line of C code?
>
>
>     FPGA(STEP_PULSE_LENGTH_ADD) = 63 + 0x80;  // set polarity and pulse length to 4us
>
>
> A common problem with stepper drives is insufficient direction setup time which can cause an occasional micro-step in the wrong direction when reversing motion.
>
> The above line stretches the pulse length and inverts it so the step occurs at the end of the pulse instead of the beginning which provides more direction setup time.
>
> Otherwise try to determine if the amount of drift is always a multiple of 4 full steps (64 microsteps) which would indicate an mechanical stepper miss-step.
>
>
> Also use the KMotion Axis Screen to check if the commanded Destination is not drifting.
>
>
> Regards
> TK
>
>
>
>
>
>
>
> ________________________________
> From: gradient_systems <james.tremel@...>
> To: DynoMotion@yahoogroups.com
> Sent: Tuesday, July 2, 2013 9:38 PM
> Subject: [DynoMotion] axis positions are slowly "drifting" through course of Gcode program
>
>
>
>  
> I am trying to get a milling machine setup using a KFlop and the Kmotion_dotNet interpreter (I am not using Mach3). I have been trying to track down a problem for the last few days. Here is a description of the problem:
>
> When running longer programs that contain small line segments (3D surfacing toolpaths) the axis positions "drift" over time. For example, tonight I chucked up a block of wax and ran the same program 3 times in a row (offsetting the origin in Y between each run).
>
> Before and after each run, I moved the spindle to a fixed Z reference location. After each run the Z axis had "moved" up ~.012". This .012" delta is very obvious in the actual cut parts; the depth of the cut at the start of the program is .012" deeper in the stock than at the end (the test was a flat part milled with successive passes in the X direction and a small step-over distance in the Y). I also verified that the depth at the start of one part is the same as the ending depth of the previous part.
>
> This is a stepper machine driven by a KStep board. My first thought was "missed steps", but I have very conservative parameters for accelerations and speeds set... and I can jog and execute simpler Gcode programs all day long and never experience a missed step.
>
> Also... the drift is ALWAYS in the same direction and opposite what I would expect from pushing the stepper past its limits (I would miss steps when raising the heavy axis and the tool would end up lower than the controller thought it was - but the tool ALWAYS ends up higher). So I am convinced this is not a problem with missed steps because the stepper can't keep up with its commanded positions. Also, this is not random... it is a linear trend from the start of the program to the end.
>
> It is not isolated to the "Z" axis either. It is easy to see that the X axis is also drifting in this test (each successive part milled in the wax is shifted in the positive X direction).
>
> Where does the troubleshooting go from here?
>

Thanks for the help Tom - you were right. The problem was with the pulse timing. After changing the polarity and width of the pulse as you instructed, the system is well behaved :).

Just curious... why is this timing not set up as the default?

The thought originally crossed my mind when beginning the troubleshooting, but I shrugged it off because I assumed you would have set the default timing if the step/direction generators to work with the KStep.

--- In DynoMotion@yahoogroups.com, "gradient_systems" <james.tremel@...> wrote:
>
> Tom,
>
> My current configuration just uses the default timing, so I will change the pulse length and try again tonight when I get time in front of the machine.
>
> On my previous machines, the default timing has seemed to work fine with your KStep driver. This is the first machine setup that I have interpreted long 3D surfacing g-code sequences with, so I guess it could just be statistics and the type of motion that is making the issues show up now.
>
> In the runs tonight I'll also find an encoder to couple to the motor shaft for better resolution on the magnitude and timing or the error.
>
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi gradient_systems,
> >
> > Have you executed this line of C code?
> >
> >
> >     FPGA(STEP_PULSE_LENGTH_ADD) = 63 + 0x80;  // set polarity and pulse length to 4us
> >
> >
> > A common problem with stepper drives is insufficient direction setup time which can cause an occasional micro-step in the wrong direction when reversing motion.
> >
> > The above line stretches the pulse length and inverts it so the step occurs at the end of the pulse instead of the beginning which provides more direction setup time.
> >
> > Otherwise try to determine if the amount of drift is always a multiple of 4 full steps (64 microsteps) which would indicate an mechanical stepper miss-step.
> >
> >
> > Also use the KMotion Axis Screen to check if the commanded Destination is not drifting.
> >
> >
> > Regards
> > TK
> >
> >
> >
> >
> >
> >
> >
> > ________________________________
> > From: gradient_systems <james.tremel@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Tuesday, July 2, 2013 9:38 PM
> > Subject: [DynoMotion] axis positions are slowly "drifting" through course of Gcode program
> >
> >
> >
> >  
> > I am trying to get a milling machine setup using a KFlop and the Kmotion_dotNet interpreter (I am not using Mach3). I have been trying to track down a problem for the last few days. Here is a description of the problem:
> >
> > When running longer programs that contain small line segments (3D surfacing toolpaths) the axis positions "drift" over time. For example, tonight I chucked up a block of wax and ran the same program 3 times in a row (offsetting the origin in Y between each run).
> >
> > Before and after each run, I moved the spindle to a fixed Z reference location. After each run the Z axis had "moved" up ~.012". This .012" delta is very obvious in the actual cut parts; the depth of the cut at the start of the program is .012" deeper in the stock than at the end (the test was a flat part milled with successive passes in the X direction and a small step-over distance in the Y). I also verified that the depth at the start of one part is the same as the ending depth of the previous part.
> >
> > This is a stepper machine driven by a KStep board. My first thought was "missed steps", but I have very conservative parameters for accelerations and speeds set... and I can jog and execute simpler Gcode programs all day long and never experience a missed step.
> >
> > Also... the drift is ALWAYS in the same direction and opposite what I would expect from pushing the stepper past its limits (I would miss steps when raising the heavy axis and the tool would end up lower than the controller thought it was - but the tool ALWAYS ends up higher). So I am convinced this is not a problem with missed steps because the stepper can't keep up with its commanded positions. Also, this is not random... it is a linear trend from the start of the program to the end.
> >
> > It is not isolated to the "Z" axis either. It is easy to see that the X axis is also drifting in this test (each successive part milled in the wax is shifted in the positive X direction).
> >
> > Where does the troubleshooting go from here?
> >
>